1. Statement of the Technical Field
The inventive arrangements relate to transaction oriented computer systems, and more specifically, to transaction processing systems that employ autonomic computing for managing transactional processing.
2. Description of the Related Art
There are many conventional Transaction Processing Systems (“TPSs”) known in the art. These conventional TPSs employ transaction software that facilitates the provision of transactional services to users of the TPSs. The transactional services enable the users to initiate transactions (or events) for generating data that is to be stored in databases of the TPSs and for modifying data that is already stored in the databases of the TPSs. There are many types of transactions. For example, there are Long Running Transactions (“LRTs”) and OnLine Transactions (OLTs). LRTs can include, but are not limited to, end of month processing, inter-bank transactions, whole bank transactions, inventory management transactions, and real time inventory transactions. More particularly, LRTs include transactions in which batches of N records are processed in multiple iterations of a processing loop. The value of N may be a fixed value or a variable whose value is varied based on response times of transactional work. Each LRT involves processing several sub-transactions (e.g., print monthly statement for account 1, print monthly statement for account 2, . . . , print monthly statement for account N) at the same time. There is a time delay between the entering of each sub-transaction and the availability of the results of the same. OLTs include, but are not limited to, user initiated commercial transactions (e.g., an electronic banking transaction, an order processing transaction, an e-commerce transaction and an eTrading transaction) in which data is entered into the TPSs and/or data is retrieved from the TPSs. More particularly, OLTs include transactions that require a short response time as compared to that of the LRTs.
Notably, TPSs are designed to provide a high degree of data integrity. The data integrity is provided by ensuring that the data managed by the TPSs is left in a consistent state. For example, if an electronic payment is made by a user of a TPS, then the amount of the electronic payment must be (1) withdrawn from the user's account and (2) added to another user's account. If the TPS can not complete both (1) and (2), then the TPS should not perform operations for providing OLT services (1) or (2). If a failure occurs that prevents completion of OLT services (1) and (2), then the partially executed transaction or event must be rolled back by the TPS, i.e., a database is restored to its previous state.
The data integrity is also provided by database locking. Database locking serves to protect shared resources and objects. The protected resources can include, but are not limited to, tables, data rows, data blocks, cached items, connections and entire TPSs. There are many types of database locking. One such type of database locking is transactional locking. Transactional locking can occur when two or more transactions are attempting to make changes to data stored in the same table, row(s) of the table and/or storage device. For example, a first user action for an LRT obtains an exclusive lock on the table when issuing a first updated statement. Subsequently, a second user action for an OLT attempts to update the same row(s) of the table. Consequently, the second user action is blocked by the exclusive lock of the first user action, i.e., the second user action cannot proceed with its transactional work until it has obtained a lock to the required transactional resources (e.g., the row(s) of the table). When the first user action commits its transaction, its exclusive lock is released and the second user action is allowed to be completed. At this time, the second user action obtains an exclusive lock to the row(s) of the table, and therefore blocks any other user actions from simultaneously modifying the data in the row(s) of the table. The following TABLE 1 illustrates the above described transactional locking.
TABLE 1TimeFirst User ActionSecond User Action1Starts Transaction2Starts Transaction3Updates Row(s) In Table4Attempts To Update Row(s)5Second User Action IsBlocked By The Lock Of TheFirst User Action6Commits Transaction7Update Row(s) In Table8Commits Transaction
As a result of database locking, concurrently executing transactions are adversely effected. This adverse effect is undesirable when high priority transactions are unable to quickly access their needed transactional resources (e.g., a row of a table). The inability of the high priority transactions to quickly access their needed transactional resources can affect specified Service-Level Agreements (“SLAs”). An SLA is a part of a service contract where the level of service is formally defined. The SLA will typically have a technical definition in terms of Mean Time Between Failures (MTBF), Mean Time to Repair (MTR), data rates, throughput, jitter and/or other measureable parameters.
WorkLoad Managers (WLMs) are typically found in TPSs. WLMs control when to start and stop processes for transactional work execution. WLMs also control the allocation of and access to system resources of the TPSs based on administrator-defined goals. The system resources include, but are not limited to, system processors, Input/Output (“I/O”) units and system storage. The goals define performance expectations for transactional work and ensure that SLAs are met for transactional workloads. Goals are often expressed as response times and relative speeds. The response time describes the duration for a transactional work request after it is entered into a TPS and until the WLM is notified that the transactional work has been completed. The relative speed is defined by the following Mathematical Equation (1).Relative Speed=100·(Total Using Samples/(Total Using Samples+Total Delay Samples))  (1)During operation, each WLM determines if the performance expectations have been met for transactional work. If the WLM determines that the performance expectations have not been met, then it will adjust the access of the transactional work to the system resources.
The actions taken by the WLMs sometimes exacerbate the aforementioned problem by allocating more system resources (e.g., central processing units) to the higher priority OLT work and/or de-allocating system resources (e.g., central processing units) to the lower-priority LRT work. But since the database locks held by the LRTs are the inherent problem, slowing down the execution of a transaction interval will actually further deny access to the needed system resources by the higher-priority OLT work. A transaction interval is the amount of time between the entering of a transactional work request into a TPS and the completion of the transactional work.
Many solutions have been employed to alleviate the above-referenced problems. A first solution includes executing LRTs at different times than when OLTs are scheduled to be executed. For example, LRTs can be executed during hours (e.g., 1 AM-5 AM) when a business organization is closed. In this scenario, the LRTs and OLTs will not compete for system and transactional resources. As such, OLT transactions will not be blocked from accessing needed system and transactional resources as a result of LRT database locks. Although this solution ensures that LRTs and OLTs will not compete from system and transactional resources, this solution does not work for many global business organizations which serve multiple time zones and geographies.
A second solution addresses CPU management for workloads of varied dispatch priorities. This solution involves assigning a dispatch priority to different units of work. For example, LRTs are assigned a low dispatch priority and OLTs are assigned a high dispatch priority. In this scenario, OLTs will be dispatched more often than LRTs. As such, OLTs are provided with more Central Processing Unit (CPU) time as compared to that provided to the LRTs. Although this solution ensures that OLTs will be provided with sufficient CPU time, it is not operative with the totality of different hardware and operating systems that are available in commerce. Therefore, not every user of the TPSs can choose the second solution.
A third solution includes statically defining commit intervals (or batch commits) associated with LRTs. The phrase “commit interval (or batch commit)”, as used here, refers to the number of items (e.g., records) that will be processed before a transaction is committed to memory. In this static scenario, TPSs lack the agility to respond to request patterns of a TPS since the commit intervals are static for the durations of LRTs. TPSs are also exposed to the possibility that higher-priority OLT work is denied access to its needed system or transactional resources while lower-priority LRT work is allowed to run.
A fourth solution involves releasing database locks in a timely fashion. This lock releasing is done under the control of the LRT applications and OLT applications. As a consequence, this solution does not offer itself as a generalized solution for users to optimized their systems and achieve overall SLA compliance across their entire workloads.